Tips & techniques for Visual dBASE and dBASE for Windows 


Figure A 


ll INSIDE VISUAL dBASE 


September 1996 ¢ Vol. 3 No. 9 
US $8.50 


Hiding important files in your EXEs 


by Keith G. Chuvala 


( “one! bullet-proof dBASE applica- 
tions for distribution can be very 
challenging. No matter how much 

experience you have or how well you know 

your clients, it’s difficult to anticipate the 
various error conditions that might occur as 
users operate your application. In this ar- 
ticle, we’ll discuss one of the most common 
problems you'll encounter when you com- 
pile and distribute an executable file, and 
we'll show you a solution. 


Problems with deleted files 


One class of error that’s particularly annoy- 
ing occurs when a user “cleans up” the hard 


When a table is missing, ugliness results. 
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drive and deletes required files from the 
directory in which a dBASE application re- 
sides. When the user subsequently tries to 
run the application, the resulting error 
message, shown in Figure A, is nothing 
short of ugly. If the user presses the Cancel 
button, the program aborts. Even worse, if 
the user presses the Ignore button, more 
error messages result! 

You can use the dBASE File( ) function 
to test for the existence of a file before an 
application attempts to use it. File() takes 
a character string or variable argument 
specifying which file to look for. It returns 
.T. if it finds the specified file and .F. if the 
file doesn’t exist. File() tests only for single 
files and doesn’t support wildcard charac- 
ters. By using File() to confirm a file’s 
existence, an application can gracefully 
handle the missing-file error condition, as 
in the following lines: 


* Handle a missing data table 

if .not. file("DATAFILE.DBF" ) 
MsgBox("The file DATAFILE.DBF is missing; 
can't continue!","An Error has Occurred") 
quit 

endif 


This approach works well, but still ren- 
ders the application unusable after it dis- 
plays the error message. What a truly 
well-behaved application needs is a way to 
create default files, or at least provide the 
option to create them, in cases where the 
user has deleted the original files. The an- 
swer lies in the Visual dBASE Compiler. 


Packaging data files in EXEs 
The Visual dBASE compiler inherits from 
its DOS ancestor an interesting capability 
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that makes it easy for your applications to 
handle missing files easily. When you cre- 
ate an executable file, you can include any 
kind of file in the EXE. 

By default, dBASE’s Build Executable 
dialog box shows only compiled program 
files. To display all files in the application 
directory for possible inclusion in the EXE 
file, click the Display All Files radio button, 


Figure B 


| jc-\ivdb4\960841 


c \ivdb4\960841 \maillist.exe 


Click Display All Files to add non-program files to your EXE. 


Listing A: Sample check for a missing file 


+» Handling missing files at program startup 
+ Check for data file. If not there, create a new one 
* 
if .not. file("maillist.dbf") && Check the current directory for 
#define Yes 6 
#define YesNoButtons 4 
if MsgBox("Create a new set of data files?",; 
“Data files not found on disk!", YesNoButtons) == Yes) 
copy file maillist.dbf to .\maillist.dbf 
+ Copy the necessary files from the .EXE to disk 
copy file maillist.dbt to .\maillist.dbt 
copy file maillist.mdx to .\maillist.mdx 
else 
MsgBox("The program will exit now. 
ad Please restore the datafiles and try again!"|: 
"No data to work with!") 
quit 
endif 
else 
use maillist order tag(1) in select() 
endif 
+ The program continues normally.... 
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as shown in Figure b. Add the files you’d 
like to package inside the EXE file to the 
Files To Build list, then click the OK button 
to create the executable file. You'll notice 
that the size of the EXE file increases ac- 
cordingly. Files you include in the EXE 
aren't compressed in any way, so adding a 
300-KB bitmap to the file list will bloat the 
EXE file by 300 KB! 


Restoring from the EXE 

Now that you’ve added the files to the 
EXE, you can copy them to the disk any 
time you need fresh copies. This safety net 
is possible because of extended properties 
of the File() function and the COPY FILE 
command. Your program can test for the 
inclusion of a file in the EXE by specifying 
a second argument in the call to File(). 
This second argument can be anything at 
all; I like to use a string that documents 
what I’m doing, as illustrated in the fol- 
lowing code segment: 


if file("maillist.dbf","Check in the .EXE file") 
MsgBox("MAILLIST.DBF is contained in the 

w EXE", "Success!") 

endif 


The COPY FILE command looks for the 
file in the EXE first; there’s no special syn- 
tax or argument to make this happen. So, 
we can use the File( ) function first to as- 
certain whether a file exists on disk, and 
then to check in the EXE file. If necessary, 
COPY FILE will create a new disk file. List- 
ing A shows a simple example of how you 
might create such a file at the beginning of 
an application. 


Another bullet dodged! 


Packaging default files in your EXE appli- 
cations can minimize or even eliminate 
ugly error messages related to missing 
files. Simply restoring a default file doesn’t 
deal with the real problem—lost or dam- 
aged data—or with the events that caused 
the file or files to be deleted or moved in 
the first place. However, using this tech- 
nique in your applications is an important 
step in creating bullet-proof applications. 
And, best of all, with File( ) and COPY 
FILE, it’s easy to do! 
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Creating pop-up menus like the pros 


Figure A 


f you've used Visual dBASE, any 

Microsoft Office application, or any 

of several other “big” Windows appli- 
cations, you’ve probably become pretty 
accustomed to—maybe even spoiled by— 
context-sensitive pop-up menus. Win- 
dows 95 has established the use of these 
right-click menus as an interface standard, 
so we know they’re here to stay. The 
menu display varies, depending on the 
object the mouse is over when you right- 
click. This practice creates a fairly intui- 
tive way to perform actions on a given 
object without requiring extensive multi- 
tiered window menus. 

Visual dBASE uses these nifty pop-up 
menus throughout the application. Borland 
added support for pop-up menus to the 
dBASE language in the transition from 
dBASE for Windows to Visual dBASE, so 
you can now add these handy menus to 
your own applications. 


Creating a pop-up menu 
You can create pop-up menus much as 
you would regular dBASE menus, though 
dBASE saves the pop-up files with the ex- 
tension POP. Figure A shows the design of 
DEFAULT.POP, a pop-up menu that offers 
commonly used options you might want to 
attach to any form you create. You'll find 
the code for this pop-up in Listing A, on 
page 4. Pop-ups are normally instantiated 
(that is, a pop-up menu object is created) in 
a form’s OnOpen event and then assigned 
to the form’s PopupMenu property. 
Listing B, also on page 4, shows the code 
for a plain form that contains nothing on it 
but the pop-up menu. Okay, so it’s not an 
award-winning form in terms of its features, 
but it efficiently illustrates the steps neces- 
sary to add a pop-up menu to a form. 
You'll notice that a form’s MenuFile 
has a simple assignment value—the 
menu’s MNU filename—while the 
PopupMenu property requires the menu 
to be already instantiated as an object. 
This seeming inconsistency actually works 
to your advantage once you graduate to 
more than one pop-up menu per form. 
Figure B shows DEFAULT.WFM with the 
pop-up menu active. 


P 
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Minimize 
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Print Setup 


You can create a pop-up menu with the Menu Designer. 


Figure B 


File Edit elp 


Here’s a simple form with the basic pop-up menu, DEFAULT.WFM, in action. 


One menu per customer, 


please 


At first glance, the PopupMenu property 
seems similar to a MenuFile property: You 


set it once and forget about it. True, you 
can do that. The DEFAULT.POP menu in 
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our example is suitable for almost any 
form. But in most applications, you'll 
want your pop-ups to change according to 
the object the mouse is currently over. 

To add this functionality, you can use 
the OnMouseMove event handler, which is 
available as part of all visible interface ob- 
jects in Visual dBASE. OnMouseMove’s 
event handler executes any time the mouse 
moves over an object, as well as every time 


the mouse moves by one pixel or more 
while over that object. 

Notice that this execution pattern is 
quite different from that of OnGotFocus’s 
event handler, which fires only once, 
when the object gets focus. OnMouseMove 
doesn’t even have a focus requirement— 
the mouse pointer just has to pass over 
any visible part of the object to trigger the 
event handler. 


Listing A: The DEFAULT.POP: A generic pop-up menu 


+» END HEADER * do not remove this lines 
+» Generated on 05/12/96 


Parameter FormObj ,PopupName 
NEW DEFAULTPOPUP( Form0bj , PopupName ) 
CLASS DEFAULTPOPUP( Form0bj , PopupName ) 
= OF POPUP(Form0bj ,PopupName ) 
this.Left = 0 
this.Top = 0 
this.TrackRight = .T. 


DEFINE MENU MAXIMIZE OF THIS: 
PROPERTY: 
Text "“Ma&ximize",: 


OnClick {; form.windowstate = 2} 
DEFINE MENU MINIMIZE OF THIS: 
PROPERTY: 
Text "Mi&nimize’,: 
OnClick {; form.windowstate = 1} 
DEFINE MENU RESTORE OF THIS: 
PROPERTY: 
Text “&Restore’,: 
OnClick {; form.windowstate = 0} 


DEFINE MENU MENUS68 OF THIS; 
PROPERTY; 
Text "",; 
Separator .T. 


DEFINE MENU PRINT OF THIS; 
PROPERTY; 
Text "&Print",; 
OnClick {; form.print()} 


DEFINE MENU PRINT_SETUP OF THIS; 
PROPERTY; 
Text "Print &Setup",; 
OnClick {; chooseprinter()} 


DEFINE MENU MENU476 OF THIS; 
PROPERTY; 
Text "",; 
Separator .T. 


DEFINE MENU CLOSE OF THIS; 
PROPERTY; 
Text "&Close",; 
OnClick {; form.close()} 


ENDCLASS 


Listing B: DEFAULT.WFM: A simple form with a pop-up menu 


** END HEADER * do not remove this line 
+» Generated on 05/12/96 
parameter bModal 
local f 
f = new DEFAULTFORM ) 
if (bModal) 
f.mdi = .F. && ensure not MDI 
f.ReadModal() 
else 
f .Open( ) 
endif 
CLASS DEFAULTFORM OF FORM 
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this.OnOpen = CLASS: :FORM_ONOPEN 


this.Text = "Simple Popup Menu Demo" 
this.Height = 16 
this.Width = 44 
this.Left = 10 
this.Top = 3 


Procedure FORM_OnOpen 
IF TYPE("Form.PopupMenu") # "0" 
DO default.pop with form, "DefaultPopup" 
form.PopupMenu = form.DefaultPopup 
ENDIF 
ENDCLASS 


Figure C 


Listing C defines a form that uses 
DEFAULT.POP and adds another pop-up 
menu, BROWSE.POP, that opens when the 
user positions the mouse over a Browse 
object on the form. This new pop-up menu 
(see Listing D, on page 6, for its source code) 
must also be instantiated; the form’s OnOpen 
event handler, FORM_OnOpen, handles that 
process for you. (Note that each PopupMenu 
object must have a unique name.) Figure C 
shows BROWSE.POP activated over the 
Browse object. As soon as the mouse moves 
off the Browse object, DEFAULT.POP be- 
comes the active pop-up menu. B3615 Big Masters, | Dorit Springer 

The BROWSE1_OnMouseMove proce- 
dure and the FORM_OnMouseMove pro- 
cedure do all the work, if you can call it 
that! Note that each procedure simply 
reassigns the form’s PopupMenu property 
to the appropriate pop-up menu. 

To add additional pop-up menus to your 
forms, you'll follow a similar three-step 


er 


Window Help 


File Edit View Form Properties 


A Beck Pertamina  ăč Martin Bajhu B. 
i Chuck Haddad = — 


es oes mari Tandan 
‘Martin Daniels 


-| Go to First Record petits 
a eae Go to Last Record a a 
7 Aspen Plannir -Randy Flood č 

Automated Ma Delete Current Record | AtdewHaldeman  ž 
Balance Compay systems M Rasmussen 
Be Martha Madarasz 


We activated BROWSE.POP by right-clicking over a Browse object. 


Listing C: A form with multiple pop-up menus 


e e 


»» END HEADER * do not remove this line» Width 92, : 


» Generated on 05/13/96 

parameter bModal 

local f 

f = new RMOUSEFORM( ) 

if (bModal) 
f.mdi = .F. && ensure not MDI 
f.ReadModal() 

else 
f.Open() 

endif 

CLASS RMOUSEFORM OF FORM 
this.OnOpen = CLASS: :FORM_ONOPEN 
this.Left = 2 
this.Top = 2 
this.Text = "Variable Popup Menu Demo" 
this.Height = 16.5 
this.Width = 98 
this.OnMouseMove = CLASS: :FORM_ONMOUSEMOVE 
this.View = "CLIENTS.DBF" 


DEFINE BROWSE BROWSE1 OF THIS; 
PROPERTY; 
Lett 3,2 
lop 0.57 
CUATab .T.,; 
FontBold .T.,; 


Text "Right-Click the mouse for special functions", ; 


Height 13.0293, ; 


OnMouseMove CLASS: :BROWSE1_ONMOUSEMOVE 


DEFINE PUSHBUTTON PB_CLOSE OF THIS; 
PROPERTY; 
Left 42,; 
Top 14,; 
Text "&Close",; 
Height 2,; 
Group .T.,; 
Width 14,; 
UpBitmap "RESOURCE #1005", ; 
OnClick {; form.close( )} 


Procedure BROWSE1_OnMouseMove(flags, col, 
form. popupmenu=form.BrowsePopup 


row) 


Procedure Form_OnMouseMove(flags, col, row) 


form. popupmenu=form.DefaultPopup 


Procedure FORM_OnOpen 
IF TYPE("Form.PopupMenu") # "0" 
DO default.pop with form, "DefaultPopup" 
form.PopupMenu = form.DefaultPopup 
ENDIF 
IF TYPE("Form.BrowsePopup") # "0" 
DO browse.pop with form,"BrowsePopup" 
ENDIF 


ENDCLASS 
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process. First, use the menu designer to cre- 
ate the POP file. Next, instantiate a unique 
variable for the pop-up menu in the form’s 
OnOpen event handler. Finally, you’ll add 
an OnMouseMove event handler for each 
object that you want to activate the new 
pop-up menu. 


Get popping! 


Pop-up menus add a nice touch to your 
applications, making them more intuitive 


Listing D: BROWSE.POP: A pop-up menu for Browse objects 


to the user and more professional in ap- 
pearance. Many of your customers and 
clients probably use Windows 95; thus 
they expect context-sensitive menu func- 
tionality and will likely notice its absence. 

Fortunately, Visual dBASE makes it 
easy for you to create and add pop-up 
menus to your applications. Now your 
programs can offer the familiar interface 
enhancements that users find in the big, 
commercial programs. + 


++ END HEADER * do not remove this line» 

* Generated on 05/13/96 

Parameter FormO0bj ,PopupName 

NEW BROWSEPOPUP(Form0bj , PopupName ) 

CLASS BROWSEPOPUP(FormObj ,PopupName) OF POPUP(Form0bj , PopupName ) 
this.Left = 0 
this.Top = 0 
this.TrackRight = .T. 


DEFINE MENU GO_TO_FIRST_RECORD OF THIS: 
PROPERTY; 
Text "Go to &First Record", ; 
OnClick {; go top} 


DEFINE MENU GO_TO_LAST_RECORD OF THIS; ag 
PROPERTY; 
Text "Go to &Last Record"; ENDCLASS 


OnClick {; go bottom} 


DEFINE MENU MENU137 OF THIS: 
PROPERTY; 


Text AE 
Separator .T. 


DEFINE MENU ADD_NEW_RECORD OF THIS; 
PROPERTY; 


Text "&Add New Record", ; 
OnClick {; form.beginappend()} 


DEFINE MENU DELETE_CURRENT_RECORD OF THIS; 
PROPERTY; 


Text "&Delete Current Record", ; 

OnClick {; if msgbox("Mark the current record for 
deletion?" "Are you sure?" ,4)=6; 

delete next 1; endif} 


PROGRAMMING TECHNIQUE 


Creating temporary (or any!) 


tables on the fly 


by Keith G. Chuvala 


omplex applications that handle 

large amounts of data often require 

the use of temporary tables, and 
dBASE provides a useful feature in its ability 
to create new tables on the fly. For example, 
you may sometimes find that it’s easier to 
write information to a temporary DBF table 
to produce a sophisticated report than it is to 
wrangle with Crystal Reports for dBASE. In 
this article, we'll discuss some of the ways 
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dBASE lets you create tables on the fly, and 
we'll explore how you can use these tech- 
niques in your applications. 

You can create tables the old-fashioned 
way, since Visual dBASE supports the 
dBASE/DOS command 


CREATE <table_name> FROM 
<structure_extended_ table> 


This command works fine, but I hate it! 


The <structure_ extended_table> needs to 
be yet another DBF or DB table containing 
specific fields, usually using the command 


COPY TO <table_name> STRUCTURE EXTENDED 


Overall, this approach is clunky at best. 
Furthermore, if a user happens to delete 
the CREATE command’s source table 
from the disk during one of those surely-I- 
don’ t-need-that-file moods, the command 
becomes useless. 


SQL to the rescue, sort of 
The SOL command CREATE TABLE 
creates a table on the fly, and it doesn’t 
require an additional file like CREATE 
FROM. There’s one problem, though-it’s 
SOL, not d(BASE—and, well, it’s kind of 
weird if you’re not used to SQL. The 
command ’s syntax is straightforward: 


CREATE TABLE <table name> (<field_name> 
<data_type> [,<field_name> 
<data_type>...] ) 


What's so weird about that? You must 
specify the <data_type> for each field as an 
SQL data type. Table A lists a number of 
SQL data types and their dBASE equiva- 
lents. Note that CREATE TABLE can create 
Paradox tables as well as dBASE tables, so 
the list of SQL data types isn’t exhaustive. 
But, the list is complete as far as mapping 
SOL data to Visual dBASE data is con- 
cerned. Both SQL types—NUMERIC and 
FLOAT—take two arguments in parenthe- 
ses: the width and the number of decimal 


Table A: SQL and dBASE data types 


dBASE Equivalent 


= Numeric (6,0) 
Numeric (11,0) 
Numeric (x,y) 
Float (x.y) 
Float (20,4) 
Character 
Date 
Logical 
Memo 
Binary 


places for the field. Similarly, the CHARAC- 
TER type takes a single argument in paren- 
theses, which specifies the width of the 
character field. 

Let’s take CREATE TABLE for a spin. In 
the Command window, enter the command 


CREATE TABLE MYCARS (MAKE CHARACTER( 12), 
= MODEL CHARACTER( 20), 

MODYEAR NUMERIC(4,0), 

ODOMETER NUMERIC(8,1), 

PURCHASED DATE, EMISSIONS BOOLEAN) 


SE SE | 


You’ve just created MYCARS.DBEF. Let’s 
look at the table’s structure. To do so, enter 
the commands 


USE MYCARS 
DISPLAY STRUCTURE 


In the Command window’s Results pane, 
you'll see the following: 


Structure for table C:\IVDB\9608\3\MYCARS.DBF 
Table type DBASE 

Number of records 0 

Last update 06/04/96 

Field Field Name Type 

MAKE 
MODEL 
MODY EAR 
ODOMETER 


Length Dec 
CHARACTER 12 
CHARACTER 20 
NUMERIC å 
NUMERIC 8 1 
PURCHASED DATE 8 

6 EMISSIONS LOGICAL 1 
ex TOtal *» 54 


one WN — 


So far so good, but... 

The SQL approach works well, doesn’t it? 
CREATE TABLE has a few shortcomings, 
though. First, it doesn’t provide a way to 
create indexes. Second, CREATE TABLE 
won't overwrite an existing table with the 
same name as the one specified in the com- 
mand. SET SAFETY OFF, which normally 
dictates that a file should be overwritten 
without warning, has no effect on CREATE 
TABLE. In addition, you get a rather for- 
bidding message when the table already 
exists, as shown in Figure A on page 8— 
which is certainly not a message you want 
your application’s users to see! 

I use temporary and other on-the-fly 
tables often enough that I created a func- 
tion that takes advantage of CREATE 
TABLE’s features while working around its 
limitations. Listing A contains the result: 


Index 


a <<a 
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MkTable( ). MkTable() takes two arguments—the name 
of the table to create, and an array containing the new 
file’s structure. 

You may think I’m borrowing trouble using an ar- 
ray, since you could argue that passing an array as an 
argument to MkTable( ) makes the function difficult to 
use. And it would be, if we were using dBASE for DOS. 
But Visual dBASE supports literal arrays. You might 
have encountered these in the Form Designer and not 
even realized what they were. A literal array is written 


with the array elements enclosed in curly braces: { and }. 


For example, try entering the following line in the 
Command window: 


x = {"first",2,35.0,date(),"five"} 


You've just created an array called X that has five ele- 
ments. Type in the command DISPLAY MEMORY to 
see the following results: 


User Memory Variables 


X Pub A [5] 
[ i) GC. “first 
[ 21 N 2.00 (2.00000000000000) 
[ 35] N 5.00 (3.00000000000000 ) 
[ 4] D 05/24/96 
[ 5] C "five" 


1 variables defined, 
499 variables available, 


25 bytes used 
4071 bytes available 


You can pass an array to a function in the same 
way. The second parameter to MkTable( ) can 
take the form 


{"Fieldiname, Type, Length, Decimals, 
rte IndexType", "Fieldiname, Type, Length, 
wh Decimals, IndexType"} 


Figure A 


CREATE TABLE MYCARS (MAKE CHARACTER(12}. K 
CREATE TABLE MYCARS (MAKE CHARACTER([12). k= 


These unpleasant results occur when you run the same CREATE 
TABLE command more than once. 
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Each string in the array contains two or more parts, 
with the parts separated by commas. The Field1name 
component must be a valid dBASE field name. Type is 
a single-character designator for the field type: C for 
character, N for numeric, F for float, D for date, L for 
logical, M for memo, O for OLE, or B for Binary. 

Length is the field width for Character, Numeric, 
and Float fields. Decimals specifies the number of deci- 
mal places to reserve for Numeric and Float fields. 
IndexType is a single character expression: A for an as- 
cending index tag, or D for a descending index tag. 


Using MkTable( ) 


Let’s use MkTable( ) to create a table called 
TEMPFILE.DBF with the following structure: 


Field Field Name Type Length Dec Index 
1 LASTNAME CHARACTER 15 N 
2  FIRSTNAME CHARACTER 12 N 
S SALARY NUMERIC 8 Z Y 
4 DATE_HIRED DATE 8 Y 


The command would take the form 


LOK = MkTable("TEMPFILE", {"Lastname,C,15", 
z "Firstname,C, 12", "Salary, N,8,2,A", 
=æ "Date_Hired,D,D"}) 


If the file was created successfully, IOK will be set to 
.T.; otherwise, it will be .F.. With this approach, your 
program can test the success of the operation. 


Conclusion 

With the CREATE TABLE command and the 
MkTable() program, your applications can create 
tables of almost any structure on demand. Use these 


e, 


tools to make your programming life easier! «% 


Other Cobb Group journals 

In addition to Inside Visual dBASE, The Cobb 
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Listing A: MKTABLE.PRG 


* 


+ MkTable(cTableName,aStructure): Create a new table on the fly cMDX = NextToken(cField) 
* if .not. isblank(cMDX) 
+ Arguments: cTableName - a string with the table name alags.add(cName ) 
* aStructure - an array of strings in the format: alags.add(cMDX) 
* FieldName, Type, Width,Decimals, Index endif 
* cSQL = cName + " FLOAT(" + cWidth + "," + cDec + ")" 
function mktable case clype = "D" 
parameter clable,aStruct,lOverwrite cMDX = NextToKken(cField) 
private cCommand,cSQL,cTableQ,aTags if .not. isblank(cMDX) 
local i,cField,cName,cType,cWidth,cDec,cMDX,cAlias alags.add(cName ) 
alags = new array() alags.add(cMDX) 
endif 
» Make sure we've got the two reqiured parameters cSQL = cName + " DATE" 
if (type("cTable") # "C") .or. (type("aStruct") # "A") case clype = "L" 
msgbox( 'MakeTable("“tablename",{array})', "Argument error!") cSQL = cName + " BOOLEAN" 
return .f. case clype = "M" 
endif cSQL = cName + " BLOB( 10,1)" 
case clype = "B" 
* Default to no overwrite if not specified cSQL = cName + " BLOB( 10,2)" 
if type("lOverwrite") # "L" case clype = "0" 
LOverwrite = .f. cSQL = cName + " BLOB( 10,4)" 
endif otherwise 
msgbox(cField+" is invalid!","Field format error") 
» Make the file name pretty endcase 
cTable = trim(ltrim(upper(cTable))) if len(cCommand) > 2 
if right(cTable,4) # ".DBF" cCommand = cCommand + "," 
cTable = clable + ".DBF" endif 
endif cCommand = cCommand + cSQL 
next 
* Delete existing file if called for 
if file(cTable) cCommand = cCommand + ")" 
#define YesNoOpts 4 cTableQ = '"'+cTable+'"' 
#define YesButton 6 CREATE TABLE &cTableQ. &cCommand 
if .not. lOverwrite 
LOverwrite = msgbox("Do you want to overwrite it?", ; * 
ctable + " already exists",; * Create indexes (if any) 
YesNoOpts) == YesButton * 
endif cAlias = alias() 
if lOverwrite select select() 
delete file (cTable) use (cTable) excl 
else for i = 1 to alags.Size Step 2 
return .f. cTag = alags[i] 
endif cOrder = alags[i+1] 
endif do case 
case cOrder $ "YA" 
cCommand = "(" && This holds all parameters for CREATE TABLE index on &cTag. tag &cTag. 
&& cSQL is used for each individual field case cOrder $ "DZ" 
for i = 1 to aStruct.Size index on &cTag. tag &cTag. descending 
cSave = upper(aStruct[i]) otherwise 
cfield = cSave msgbox(cOrder + " is invalid. Use A or D",; 
cName = trim(ltrim(NextToken(cField) )) “Invalid sort order!") 
cType = trim(ltrim(NextToken(cField))) endcase 
do case next 
case clype = "C" use 
cWidth = NextToken(cField) if len(trim(cAlias)) > 0 
cMDX = NextToken(cField) select (cAlias) 
if .not. isblank(cMDX) endif 
alags.add(cName ) return .t. 
alags.add(cMDX) 
endif function NextToken 
cSQL = cName + “ CHARACTER(" + cWidth + ")" 
case clype = "N" parameter cString 
cWidth = NextToken(cField) Local nComma,cRetVal 
cDec = NextToken(cField) nComma = at(",",cString) 
cMDX = NextToken(cField) if nComma > 0 
if .not. isblank(cMDX) cRetVal = left(cString,nComma - 1) 
alags.add(cName ) cString = substr(cString,nComma+1 ) 
alags.add(cMDX) else 
endif cRetVal = cString 
cSQL = cName + “ NUMERIC(" + cWidth + "," + cDec + ")" coiring =" 
case clype = "F" endif 
cWidth = NextToken(cField) return cRetVal 
cDec = NextToken(cField) 
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DISPLAY TIP 


Tipping the Scale(font)s 


ne of the neat things about 

Windows—for users—is the 

varied array of video resolutions 
available. At the same time, one of the 
bothersome things about Windows—for 
developers—is the varied array of video 
resolutions available. Long gone are the 
days when we software developers could 
make assumptions about the kinds of 
video cards our software would have to 
support. Now, we have to be smarter than 
the machines. 


Let’s make this perfectly clear 


The Windows operating systems and Win- 
dows applications do their best to be device 
independent. The hardware shouldn’t matter 
to your application. That is, a Windows- 
based program should be able to run on 
any video card supported by a Windows 
driver, and at any resolution supported by 
a Windows driver. 

Video resolution is measured in pixels. 
A pixel is the single smallest dot of light 
that can be displayed on the computer’s 
monitor. A standard VGA card runs a 
maximum resolution of 640 pixels horizon- 
tally and 480 pixels vertically. Most video 
cards sold for the past few years have far 
exceeded the capabilities of standard VGA, 
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supporting resolutions as high as 1280 x 
1024—and sometimes even higher! 

Smaller monitors usually run at lower 
resolutions, and larger monitors run at 
higher resolutions. The higher the resolution, 
the more information you can display on the 
screen, but also the smaller each pixel—and 
therefore each item on the screen—becomes. 

Deciding which resolution to use is gen- 
erally a matter of choosing the highest value 
you can use comfortably on the monitor 
attached to the system. For example, I have 
a laptop computer running at 640- x 480- 
pixel resolution, a desktop machine at home 
with a 14-inch monitor that I run comfort- 
ably at 800 x 600 pixels, and a machine at 
the office with a gorgeous, 17-inch monitor 
that I run at 1024 x 768 pixels. 

Creating applications that can resize 
their forms and other visual elements to 
match the resolution of the screen can be 
tricky. Fortunately, Visual dBASE forms 
have a couple of properties to make the job 
easier: ScaleFontName and ScaleFontSize. 


The ScaleFont properties 
Before we get into the specifics of using 
ScaleFontName and ScaleFontSize, let’s 
talk about how Visual dBASE measures 
elements. Working in pixels can be frus- 
trating, because they don’t directly corre- 
spond to any part of an application. 

The sizes of Visual dBASE objects, such 
as forms and pushbuttons, aren’t mea- 
sured in pixels. Instead, dBASE measures 
the height and width of each element in 
character boxes. A character box is approxi- 
mately the amount of space that a charac- 
ter occupies onscreen when you’ve 
chosen a particular font at a particular 
size. It’s sometimes easier to think of these 
boxes in terms of rows (vertical resolu- 
tion) and columns (horizontal resolution). 
So, a form with a Height property set 
to 20 and a Width property set to 60 is 
approximately 20 rows (or characters) 
high and 60 columns wide. 

The grid that Visual dBASE uses to keep 
track of these rows and columns is called 
the coordinate plane. The ScaleFontName 
and ScaleFontSize properties specify the 


Use the Navigator to select the Visual (BASE SAMPLES directory. font used to calculate the size of each char- 
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acter box on a form. If you change the font 
and/or size used, you change the number 
of rows and columns that can fit on a form. 


Try it! 
Let’s use one of the sample forms in- 
cluded with Visual dBASE to illustrate 
the effect these two properties have on a 
form. In the Navigator, select the direc- 
tory that contains the Visual dBASE 
sample files, as shown in Figure A. On 
my system, it’s C:\VDB\SAMPLES. If 
you installed Visual dBASE in the default 
location, the directory will probably be 
C:\VISUALDB\SAMPLES. 

In the Command window, type the fol- 
lowing commands to create a new form 
object from the ANIMALS.WFM file: 


SET PROCEDURE TO ANIMALS .WFM ADDITIVE 


F = NEW ANIMALSFORM( ) 
F.OPEN( ) 


The first line makes the form specified in 
that file available to us from the Command 
window. The second line creates a form 
called F that we can play with, and the third 
line opens the form, as shown in Figure B. 
ScaleFontName’s default value is MS 
SanSerif, which is not a scalable font. Let’s 
change the ScaleFontName property to 
Arial by typing in the Command window 


F.ScaleFontName="Arial" 


Did you notice a slight change in the 
size of the form? The character box size of 
the Arial font is slightly smaller than that 
of the MS SanSerif font, and the form ad- 
justs itself accordingly. 

Now let’s play with ScaleFontSize. The 
default is 10. Let’s increase the size and watch 
the effect. In the Command window, enter 


F.ScaleFontSize=14 


Wow! Notice how everything got larger? 
The form itself, the buttons, entry fields, 
text objects—and even the image control 
containing the picture of the Angel Fish— 
grew, as shown in Figure C. Try other 
ScaleFontSize settings and watch the form 
rescale itself. 


It’s a start 


For optimal benefit, the fonts you use for 
your pushbuttons, entry fields, and so on, 


Figure B 
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ROCEDURE TO ANIMALS "WFM ADDITIVE 


F = NEW ANIMALSFORM{) 
F.OPEN() 


sT 
Sample Information 
o 


Object 
Master index: NAHE 
? 


I 
animals. win 


We opened this Animals form from the Command window. 
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S ROCED IMALS WFM ADDITIVE 
F = NEW ANIMALSFORM[) 

F.OPEN 

F.ScaleFontName="Arial" 

F.ScaleFontSize=14 


as 


Navigator 


Our Angel Fish is putting on weight! 


should be scalable. Arial works well, but 
any TrueType, Type 1, or other scalable 
font will behave similarly. 

There’s much more to be explored on this 
topic. In a future issue, we'll examine other 
ways to use ScaleFont, and we’ll present 


}, 


additional resizing tricks and techniques. + 
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SYSTEM SECURITY 


Implementing password-protected 
login access to Visual dBASE 


Please note this advance warning: Use extreme 
caution in trying the technique we describe in 
this article. If you forget the password you cre- 
ate for yourself, you may be forced to re-install 
the program to regain access. 


confidential databases, you can protect 

sensitive information from roving eyes 
by copying an important file onto a floppy 
disk, erasing it from the hard drive, taking 
the disk home with you after work every 
day, and restoring the file every morning. 
Even using that method of security with 
your files comes with a fair amount of 
risk—after all, you'd be in big trouble if 
you lost or damaged the diskette. 

Fortunately, Visual dBASE provides a 

number of built-in tools you can use to 
keep your files safe. In this article, we'll 
take a look at Visual dBASE’s first level of 


i you use Visual dBASE to maintain 


You'll use this dialog box to implement password pro- 
tection for Visual dBASE. 


Figure B 
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ables 4 Enforcement f — 


This dialog box lets you access your system’s 
security features. 
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security—login access—by showing you 
how to password protect entry to Visual 
dBASE itself. (In a future issue, we’ll intro- 
duce you to the other two methods of se- 
curing your data: data encryption, and 
table and field security.) 


Keeping the rascals out 
Suppose you've installed Visual dBASE on 
a computer that’s located in a public area, 
and you want to make sure no one but you 
can run the program. To do so, you define 
three login parameters for yourself: a 
group name, a login name, and a pass- 
word. Then, the next time you try to start 
Visual dBASE, a dialog box prompting you 
to enter those values will appear. If you fail 
to enter the correct login values, Visual 
dBASE simply won’t run. 

To begin, start Visual dBASE and 
choose Database Administration... from 
the File menu. When you do, the Database 
Administration dialog box appears, as 
shown in Figure A. 

The first item in the Database Adminis- 
tration dialog box tells Visual dBASE what 
types of databases to display in the Navi- 
gator. The type of table can affect whether 
security features are available. Typically, 
you'll accept the default value of DBASE 
for this option. 

Now, click the Security... button. 

The first time you do, the Administrator 
Password dialog box appears. Type the 
password you'll use as the database ad- 
ministrator. Once you define the adminis- 
trator password, keep a hard copy of that 
password in a secure place. 

Note: There is no way to retrieve this 
password from the system. After the first 
use, the Administrator Password dialog 
box controls access to the security features, 
and it will appear each time you click the 
Security... button. You can change the se- 
curity system only if you first supply the 
administrator password. 

You still have a little more work to do 
to prevent unwelcome access to Visual 
dBASE. After you enter the administrator 
password, the Security dialog box appears, 
as shown in Figure B. 


Now, make sure the Users tab is se- 
lected, and then click the New... button. 
When you do, the New User dialog box 
appears. The User box lets you specify the 
login name for a user. Enter a name from 
one to eight alphanumeric characters in 
length. (Visual dBASE converts the entry to 
uppercase.) You can enter up to 8 charac- 
ters for the Group name and up to 16 char- 
acters for the password, including spaces. 

When you define the password, you can 
enter either uppercase or lowercase letters. 
The password isn’t case-sensitive: You just 
have to remember how to spell it. 

Visual dBASE also lets you enter spaces in 
the password—both when you define it and 
when you enter it to access the program. 
However, you'll discover that Visual dBASE 
ignores the spaces. That is, whether or not 
the original password you define contains 
spaces, you can include or omit spaces when 
you type the login password—Visual dBASE 
considers only the non-space alphanumeric 
characters you type. 

As an option, you can include the full 
name of the user whose profile you’re de- 
fining. At this point, you can accept the de- 
fault value of 1 for the Access Level; we'll 
talk more about that option later. Figure C 
shows a sample user profile. 

Next, you must tell Visual dBASE when 
to restrict access to qualified users. To do 
so, click the Enforcement tab and the When 
Loading Visual dBASE radio button. Then, 
close all the open dialog boxes and exit Vi- 
sual dBASE. The next time you load Visual 
dBASE, you'll see the login dialog box. 
(This dialog box makes no mention of the 
Access Level you set when you defined the 
login information for this user; that’s be- 
cause the Access Level becomes important 
only when you implement table—or table 
and field—security measures.) 

If you click the Visual dBASE Login dia- 
log box’s Cancel button, the program will 
return to your operating system. If you en- 
ter an incorrect value in any of the fields, 
the system will issue a warning message. 
For instance, if you type DABULL instead 
of DABULLS in the Group field, Visual 
dBASE will display an error message. 

If you attempt to gain access three times 
without providing the correct login infor- 


mation, the program will fail to load and will 
return you to the operating system. You’ll 
have to double-click the program icon again if 
you want to try logging in once more. 


Disabling login protection 
Now that you know how to prevent un- 
wanted users from gaining access to Visual 
dBASE, you probably want to know how 
to disable such protection. Doing so is 
easy, as long as you remember your ad- 
ministrator password. Just choose Data- 
base Administration... from the File menu, 
click the Security... button, and enter that 
all-important password. 

Then, when the Security dialog box ap- 
pears, you can delete the user profile by 
clicking the Delete button. Or, you can 
leave the user profile intact and simply 
change the way Visual dBASE enforces 
password protection. Specifically, you’d se- 
lect the Enforcement tab and select the 
When Loading An Encrypted Table radio 
button instead of the When Loading Visual 
dBASE radio button. 


Conclusion 

In this article, we showed you how Visual 
dBASE lets you control access to its envi- 
ronment. In future issues, we'll show you a 
similar approach to protecting data by 
encrypting a table’s contents or by restrict- 
ing a user’s access to a table or to a field 
within a table. * 


Figure C 


Define login access privileges for your users in this 
dialog box. 
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OBJECT-ORIENTED PROGRAMMING 


Protect your properties 


f you browse through the source code 

for the custom controls included with 

Visual dBASE, you'll notice a new use 
for the word PROTECT. PROTECT is 
known to many dBASE programmers as 
the password and table security system 
introduced to dBASE for DOS back in 
the 1980’s. Now there’s a new spin on 
PROTECT that also has to do with security, 
though ina very different way. 


A class background 

Custom Controls should be constructed so 
they function as “black boxes” —as self- 
contained and self-reliant as possible. The 
object-oriented programming concept 
known as encapsulation provides a mecha- 
nism whereby we can include both code 
and data in a single unit that we call an 
“object.” We create the definitions of these 


objects using the now-familiar construct 
CLASS e ENDCLASS 


Why protect properties? 
Often the properties you create inside a 
custom class are used only by the proce- 
dures and functions within that class. 


Listing A: DBFBROW.PRG with unprotected properties 


dBASE’s default behavior, however, is 
such that any code can change any custom 
property in any class, whether the change 
makes sense or not! So, good OOP design 
calls for a mechanism to—you guessed it— 
protect properties from improper modifica- 
tion from outside the class. 

Listing A, DBFBROW.PRG, contains the 
code for a custom class that creates a new 
session and triggers a BROWSE window 
with a specific title. You call it like this: 


set procedure to dbfbrow 

X S 

new dbfbrow("c:\vdb\samples\customer","Customers 
= on File") 


Or, you can create the object first and set the 
TableName property in a separate command: 


set procedure to dbfbrow 
x = new dbfbrow( ) 
x.SetTableName("c:\vdb\samples\customer" ) 


You can see the results in Figure A. As 
long as you follow the rules, this command 
works great. If you don’t, the object is 
easy to break, too! 


Usage: 


NOTE! 


* 
* 
* 
* 
* 
* 
* 
* 
* 


CLASS DBFBROW 


DBFBROW: Create an on-the-fly BROWSE 


SET PROCDURE TO DBFBROW 
x = NEW DBFBROW("table_name", "Window Title") 


CLASS: :SetTableName() can be called to set or reset the table name 


Custom properties are NOT protected; 
use care not to change their type! 


parameters clable, cTitle 


this. tablename 
this.title 
this. browsing 


iif(type("cTable") 
iif(type("cTitle") 
‘Ts 


"C" cTable,"") 
"C" cTitle,"Table View") 


PROTECT tablename,title,browsing 


if .not. isblank(this.tablename ) 


this.show( ) 


return 


procedure SetTitle 
parameter cTitle 
if type("cTitle") = "C" 
this.title = cTitle 
endif 
return 


procedure Show 
if .not. isblank(this.tablename ) 

if .not. this.browsing 
create session 
use (this. tablename ) 

else 
use 

endif 

this.browsing = .t. 

if .not. isblank(tag(1)) 
set order to (tag(1)) 


endif endif 
go top 
procedure SetTableName browse title (this.title) 
parameter clable endif 
if type("cTable") = "G" return 
this. tablename = cTable 
endif ENDCLASS 
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Where’s the real problem? 


Let’s try an experiment. Suppose you 
change the TableName property to the 
wrong data type: 


» PROBLEM.PRG - breaks the DBFBROW class 
set procedure to dbfbrow 

x = new dbfbrow( ) 

x.TableName = .f. 

x .Show( ) 


Setting the TableName property to .F. is, 
well, dumb. But it’s also entirely legal syn- 
tactically. So, this code would compile just 
fine. When you run the program, however, 
you ll get an error, as shown in Figure B. 

Of course, this kind of error is going to 
happen no matter how careful you are, espe- 
cially in large projects. The real (and avoid- 
able) problem, then, is that the error message 
tells us where the program stopped in the 
DBFBROW class, which is not where the ac- 
tual programming error is situated! You 
need to know the location of the code that 
incorrectly changed the data type of the 
TableName property to begin with. 

Here’s where PROTECT can prevent 
runtime errors. Listing B, on page 16, 
shows another version of DBFBROW.PRG. 
The only difference between this one and 
the previous class definition is the addition 
of PROTECT to prevent unwanted modifi- 


Figure A 


This is DBFBROW in action as it’s meant to be. 


Figure B 


ig 


Ugliness and a less-than-helpful error message result when 
you change the type of the TableName property. 


cation of the TableName, Title, and Brows- 
ing properties from outside of the class. 
Now let’s run the problematic code again, 
and look at the change in the error 
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Figure C 


message, as displayed in Figure C. PRO- 
TECT doesn’t save us from making errors, 
but it does enable dBASE to tell us the loca- 
tion of the real problem in our code. We 
can now go right to the cause of the error. 
PROTECTed properties are also hidden 
from view in the object inspector, even in 


With PROTECT in force, the error message now tells us that 
the real problem lies in line 4 of PROBLEM.PRG. 


Listing B: DBFBROW.PRG with protected properties 
SERS 


+ DBFBROW: Create a safe on-the-fly BROWSE 

* Usage: SET PROCDURE TO DBFBROW 

* x = NEW DBFBROW("table_name", "Window Title") 

* CLASS: :SetTableName() can be called to set or reset the table name 


CLASS DBFBROW 


parameters clable, cTitle 


this.tablename 
this.title 
this. browsing 


= 1if(type("cTable") = 
iif(type("cTitle") = "C" cTitle,"Table View") 


"C" cTable,"") 


PROTECT tablename, title, browsing 


if .not. isblank(this.tablename) 


this.show( ) 
endif 


the Form Designer. The inspector normally 
displays unprotected properties on the 
Properties tab. PROTECTing properties 
hides them from view. This behavior 
makes a lot of sense, since the main goal of 
PROTECT is to prevent unwanted modifi- 
cation of properties from outside the class. 
If you create a visual custom class for use 
on your forms, any data that you PROTECT 
won't be visible in the Form Designer’s 
Inspector window. 

PROTECT is a smart new capability; 
start making it a part of your custom 
classes whenever a property is intended 
for use only inside the class. PROTECT can 
make error messages arising from logic 
problems more useful, prevent unwanted 
clutter and confusion in the Inspector win- 
dow, and help you create a more solid, 


+, 


bullet-proof class design. 


procedure SetTitle 
parameter clitle 
if type(“cTitle") = "C" 
this.title = cTitle 
endif 
return 


procedure Show 
if .not. isblank(this.tablename) 

if .not. this. browsing 
create session 
use (this. tablename ) 

else 
use 

endif 

this. browsing = .t. 

if .not. isblank(tag(1)) 
set order to (tag(1)) 


endif 

procedure SetTableName go top 

parameter cTable browse title (this.title) 

if type("cTable") z mi endif 

this.tablename = cTable return 

endif 

return ENDCLASS 
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